실제 제품을 만드는 관점에서 LLM은 ‘두뇌’일 뿐이다

AI 제품을 만들 때 가장 흔한 착각이 있다.

“LLM API 붙이면 된다”

하지만 실제 제품을 만들면 금방 깨닫는다. LLM은 생각은 할 수 있지만 행동은 못한다.

예를 들어 사용자가 이렇게 말한다.

“출장 일정 만들어줘”

LLM은 텍스트를 생성할 수는 있지만 다음 작업을 수행하지 못한다.

• - 항공편 검색

• - 호텔 가격 비교

• - 일정 생성

• - 캘린더 등록

즉 LLM은 추론 엔진일 뿐이다.

실제 제품을 만들려면 행동을 수행하는 시스템이 필요하다. 이 구조가 바로 AI Agent Architecture다.

실제 Agent 아키텍처

실제 서비스에서 가장 기본적인 Agent 구조는 다음과 같다.

User
 ↓
Orchestrator
 ↓
LLM (Reasoning)
 ↓
Tool Router
 ↓
External Tools
 ↓
Memory

각 컴포넌트는 명확한 역할을 가진다.

1. Orchestrator

전체 에이전트 실행을 관리하는 레이어다.

예를 들어

• - 요청 분석

• - 실행 루프 관리

• - tool 호출 제어

보통 다음 형태로 구현한다.

• Python Agent loop , LangGraph , Temporal workflow

이 루프가 Agent 실행 엔진이다.

2. Planner 구현

Planner는 목표를 작업 단계로 분해한다.

예를 들어 , 사용자 요청가 아래와 같다면

출장 일정 만들어줘

Planner 출력

1. 항공편 검색
2. 호텔 검색
3. 일정 생성

Planner는 보통 LLM prompt로 구현한다.

예

You are a planning AI.
Break the user request into steps.

Return JSON.
User request:
출장 일정 만들어줘

출력

{
 "steps":[
  "search flight",
  "search hotel",
  "create itinerary"
 ]
}

이 결과가 Agent 실행의 작업 큐가 된다.

3. Tool Layer 설계

Agent 시스템에서 가장 중요한 부분이 Tool Layer다.

Tool은 AI가 사용할 수 있는 실제 기능이다.

예

search_flight()
search_hotel()
create_calendar_event()
send_email()

보통 Tool은 다음 형태로 정의한다.

class Tool:

    name = "search_flight"
    description = "Search flight tickets"
    def run(self, query):
        return flight_api(query)

그리고 LLM이 tool을 선택하게 한다.

예

Available tools:
search_flight
search_hotel
create_calendar_event

LLM 출력

{
 "tool":"search_flight",
 "arguments":{
  "from":"Seoul",
  "to":"Tokyo"
 }
}

이 구조가 Function calling / Tool calling이다.

4. Agent 실행 루프

Agent는 보통 loop 구조로 동작한다.

1 user request
2 plan 생성
3 tool 선택
4 tool 실행
5 결과 평가
6 다음 행동 결정

이 loop가 Agent reasoning cycle이다.

5. Memory 설계

Memory는 보통 3개 레이어로 나뉜다.

• 1) short-term memory

현재 작업 context

conversation history
current task
tool results

보통은

context window

로 관리한다.

2) long-term memory

사용자 정보와 했던 정보를 압축하여 저장한다.

이는 정보자체를 압축하여 저장하거나, 별도 db를 만들어서 저장하는것이 좋다.

예

user preferences
previous tasks
history

보통

vector DB

를 사용한다.

예

• Pinecone

• Weaviate

• pgvector

3) working memory

Agent 작업 상태

예

current plan
task state
intermediate results

이건 보통 메모리 기반 Redis나 state store에 저장한다.

실제 Agent 아키텍처 (현업 구조)

실제 서비스는 보통 이렇게 생긴다.

Frontend
  ↓
API Gateway
  ↓
Agent Service
  ↓
LLM Service
  ↓
Tool Service
  ↓
External APIs
  ↓
Memory Store

예

Next.js
FastAPI Agent
OpenAI API
Redis memory
Postgres
External tools

Agent 시스템의 진짜 어려운 부분

많은 사람들이 Agent 구현을 어렵게 생각하지만 진짜 어려운 부분은 따로 있다.

1. 1. tool reliability

AI가 tool을 잘못 호출한다.

2. hallucination

없는 API를 호출한다.

3. loop 문제

Agent가 무한 루프에 빠진다.

4. cost 문제

tool + LLM 호출이 많아진다.

그래서 실제 서비스에서는 다음을 추가한다.

• - tool validation

• - step limit

• - cost guardrail

• - fallback logic

정리

AI Agent는 단순한 개념이 아니다. 실제 시스템으로 보면 다음 구조다.

LLM → reasoning
Planner → task decomposition
Tools → action
Memory → context
Orchestrator → execution loop

이 다섯 가지가 결합되어야 실제로 일을 수행하는 AI 시스템이 만들어진다.

2편 https://letspl.me/quest/2355/shortcut

3편 https://letspl.me/quest/2356/shortcut